The commercial success of a software application can rely upon the ability to provide the application in several versions that are each suitable for a different operating system, e.g. "MICROSOFT WINDOWS", "UNIX", "MS-DOS", "APPLE MACINTOSH", and so on. For this reason, it is traditionally necessary to develop separate versions of a software application for each operating system from a single problem specification in order to obtain a commercial software product that will be useful to users of different operating systems.
A continuing trend in the field of software engineering is to allow the programmer to design applications at increasing levels of abstraction. The earliest "programs" were entered into a computer by a bit-level mechanism; such as toggle switches, punch cards, or paper tape; and the job of the programmer was to specify the bit-patterns corresponding to the machine-language instructions that would cause execution of the application. Then, as applications became more sophisticated, symbolic assembly languages were developed to enable the programmer to specify a program in terms of mnemonic codes that represented one or more machine-language steps.
The next level of abstraction was the development of high level languages, so that more complicated functions, constituting modules of assembly code, could be expressed in terms of single commands of a high level language. In order to execute a high-level program, the source code is first compiled to produce assembly code, and then the assembly code is translated into the machine code. Even with high-level languages, the desire for more sophisticated applications has surpassed the ability of a single programmer, or team of programmers, to produce the required quantity of code, or even to test and de-bug large-scale applications at the level of abstraction provided by high-level languages.
Concurrent with the growth of high-level languages, certain routine procedures have been delegated to the operating systems of computers. For example, the presentation of information in a graphical user interface (GUI) does not require the application programmer to re-write the GUI routines for each application. Modern operating systems incorporate routines, e.g. for window display operations, that can be accessed by system calls from the application to the operating system. Such routine procedures that are provided by an operating system shall herein be referred to as native features of the operating system.
Object-oriented programming is gaining popularity as a software design technique for the development of complex applications. In the object-oriented paradigm, a library of basic functional units having their own code modules and data structures are linked together in accordance with the specification of a problem. Each of the functional units, or objects, is independently designed to communicate with other objects in a specified manner so that the programmer is merely required to specify abstract functional relationships among the selected objects, and the messages to be communicated among the objects, in order to produce an application. Additionally, general classes can be customized when needed to define a subclass. A subclass of a given class inherits particular characteristics from the classes from which it depends.
The computer system that is used in the creation of an object-oriented structure is herein referred to as a development environment. The development environment includes a library of objects, a set of tools for selecting objects from the library and for specifying functional or semantic inter-relations among the selected objects. The development environment must be compatible with the operating system of the computer within which the development environment is installed. The inherent necessity for an object-oriented development environment to function in the context of a particular operating system has hampered the ability of object-oriented programming to be a general technique for producing applications that are independent of the operating system of the development environment.
Since the development environment is, itself, an application, the objects therein usually rely upon native features of the operating system of the computer system within which the development environment exists. Additionally, object-oriented development environments that have been produced for use with different operating systems have not provided a uniform object library or uniformly convenient development tools for producing object-oriented structures within each environment. Hence, although object-oriented programming techniques have enabled progress in the rapid development of complex structures for use in the context of a single operating system, the problem of providing an object-oriented structure in various forms that are each suitable for different operating systems still requires the separate development of different native versions of the same structure. In the development of structures that require customization of a particular class in order to produce a desired object, the problem is compounded, since one of the important advantages of object-oriented programming (i.e. the ability to re-use customized objects) is then lost when the structure must be re-developed within each desired target operating system.
The need to re-develop object-oriented structures for use in different operating systems reduces the productivity of the software engineer. In order to re-develop the structure for each operating system, the software engineer must, of course, use only the development tools that are available for each operating system. Hence, the software engineer must become familiar with the different development tools for performing the same task within each respective operating system. Additionally, development of an object-oriented structure in one environment may be a relatively simple task, while re-development in another environment may be more time-consuming because not all development environments are equally powerful or easy to use.